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SHORT MESSAGE DISTRIBUTION CENTER 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

5 This invention relates generally to wireless carriers, Internet 

service providers (ISPs), and information content delivery 
services/providers. More particularly, it relates to Wireless 
Telecommunication, ANSI-41D Wireless Intelligent Network (WIN) 
applications, and SMTP protocol to manage information content for a 
10 wireless carrier. 

2. Background of Related Art 

There are many "wireless" information content providers in 
the industry who have some information or service that is considered of 
15 value to the mobile phone user. Wireless Carriers are typically in favor of 
these content providers as they add value to Short Messaging Systems 
(SMS) and can drive up SMS and voice usage. 

Unfortunately, content providers may not fully understand a 
particular wireless network and/or may not be fully sensitized to particular 
20 needs of carriers. This is because the carrier is often seen simply as a 
'pipe' through which wireless messages are sent using SMTP protocol. 
Content providers maintain their own subscriber lists, and typically 
communicate with carriers merely as e-mail hosts. 

All traffic is typically sent through an SMTP gateway, and 
25 thus information content, ads, etc., cannot be differentiated from higher 
priority 'personal' content. Problems arising from this include: 

Bulk information content can slow down and even 
jeopardize the carrier's SMTP Gateway performance; 

Personal messages cannot be given a higher priority 
30 than bulk messages; 
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Bulk info content receives the same messaging 
parameters as personal messages, e.g., delivery receipts 
enabled, expiration date of 3-5 days, etc.; 

The carrier cannot differentiate between bulk 
5 messages among various providers and personal mail for 

billing purposes; 

Bulk senders deliver their content regardless of 
whether the device is on, and thus the carrier must handle 
message storage and retry attempts; and 
10 - Bulk senders will typically continue to deliver content 

to churned wireless subscribers, wasting network resources 
and interfering with reuse of mobile numbers. 
There is a need for a technique using SMTP and/or other 
conventional protocols to enable an easy way for content providers to 
15 distribute and/or differentiate their information without requiring them to 
change technologies. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Features and advantages of the present invention will 
20 become apparent to those skilled in the art from the following description 
with reference to the drawings, in which: 

Fig. 1 shows a high level sequence diagram including a 
Message Distribution Center (MDC) enabling a Content Provider to direct 
messages via SMTP to the Message Distribution Center (MDC), in 
25 accordance with the principles of the present invention. 

Fig. 2 illustrates exemplary software components and their 
relationships in an embodiment of a message distribution center (MDC), in 
accordance with one embodiment of the present invention. 
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Fig. 3 is an exemplary class diagram which shows further 
details of an embodiment of a Message Distribution Center, in accordance 
with the principles of the present invention. 

SUMMARY OF THE INVENTION 

In accordance with the principles of the present invention, a 
message distribution center is interposed between a source of a short 
message and a wireless network including an intended recipient of the 
short message. The message distribution center comprises an SMTP 
protocol communication channel to receive the short message from the 
source of the short message. A plurality of subscriber queues are 
included, each corresponding to a different subscriber in the wireless 
network. The short message is placed in at least one of the plurality of 
subscriber queues before delivery to the wireless network. A 
communication channel communicates the short message to the wireless 
network. 

In accordance with another aspect of the present invention, 
a method of throttling short messages to subscribers in a wireless network 
comprises forwarding a short message to a wireless network only when a 
receiving wireless device in said wireless network is known outside said 
wireless network to be online. 

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

The present invention enables a Content Provider to direct 
messages via SMTP to an intermediatary Message Distribution Center 
(MDC) using standard SMTP Gateway and other well-known protocols. 

In accordance with the principles of the present invention, 
short messages are inserted in the MDC into individual queues for each 
subscriber, and the provider is informed through conventional SMTP 
protocol messages that the short message has been accepted. 



If the carrier has specifically disallowed service for a MIN 
(e.g., in the case of churning), then the content provider is informed 
through an SMTP interchange that the recipient is invalid. This 
encourages providers to discontinue service to terminated MINs, thereby 
5 reducing traffic to the MDC. 

A Message Distribution Center (MDC) provides value to both 
wireless developers and wireless carriers. For instance, for the Wireless 
Developer, an MDC provides a single mechanism for interacting with 
subscribers of multiple carriers, regardless of each carrier's underlying 
10 infrastructure. For the carrier, an MDC can protect their SS7 network by 
intelligently throttling messages and configuring message delivery 
2 parameters to be more network friendly. 

y An MDC acts as a broker between carriers and developers. 

q Different levels of relationships can be established with both carriers and 

^ 15 developers, resulting in different levels of services that are available. The 
MDC interacts with a carrier's Short Message Service Center(s) (SMSCs) 
J and/or SS7 network, allowing developers to guarantee message delivery, 

;~ to interact with users via Mobile Terminated (MT) and Mobile Originated 

□ (MO) SMS, and possibly even to receive handset presence information. 

20 Although the disclosed embodiments relate primarily to 

wireless services from the perspective of a Short Message Service (SMS), 
the disclosed MDC and related management middleware may support 
many types of wireless devices using the same API. For instance, 
suitable supported devices may include, e.g., 2-way Email pagers, the 
25 Palm VII™, and wireless application protocol (WAP) devices. 

The disclosed MDC utilizes a Wireless Internet Gateway 
(WIG), which is a middleware messaging platform designed to facilitate 
communication between Internet devices and various wireless networks. 
A suitable WIG is disclosed in U.S. Appl. No. 09/630,762 to SMITH, 
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entitled "Wireless Internet Gateway", filed August 2, 2000, the entirety of 
which is expressly incorporated herein by reference. 

Fig. 1 shows a high level sequence diagram including a 
Message Distribution Center (MDC) enabling a Content Provider to direct 
5 messages via SMTP to the Message Distribution Center (MDC), in 
accordance with the principles of the present invention. 

In particular, as shown in Fig. 1, an MDC 100 is placed 
intermediary between a content provider 120 and a wireless carrier 130, 
to allow management of message delivery for each of a plurality of 
10 subscribers. As shown in Fig. 1, the content provider 120 communicates 
with the MDC 100 using SMTP protocol messages, and the MDC 
communicates with the wireless carrier 130 preferably using RMI/SMPP 
techniques. 

Importantly, the MDC 100 includes a plurality of subscriber 
15 queues 150, preferably one for each subscriber having MDC support. 
The subscriber queues 150 may be integrated within the gateway of the 
MDC 100, or may be external to the gateway of the MDC 100 but 
nevertheless in direct communication with the gateway of the MDC 100. 

The subscriber queue 150 preferably follows a First In 
20 First Out (FIFO) model, where the oldest messages are delivered first. 

In accordance with the principles of the present invention, a 
particular wireless carrier 130 assigns a value for the maximum number of 
outstanding messages for a particular subscriber. This maximum number 
of outstanding messages can be used to establish a queue threshold. 
25 Thus, if one or more new messages cause the queue threshold to be 
exceeded, then the oldest messages may be deleted first from the 
particular subscriber queue 150 to make room for the new message(s). 
Of course, the subscriber queue 150 may be expanded in size as desired. 

To provide protection from constantly growing subscriber 
30 queues 150, other rules may be established by the wireless carrier 130 to 
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allow automatic deletion of particular messages from the subscriber 
queue 150. 

For instance, an expiration period may be established 
whereby all messages more than x days old are removed. The expiration 
period may be established, e.g., on an individual subscriber basis (e.g., 
different subscription plans allowing larger queues and/or longer storage 
times), or on a global basis (e.g., all subscribers in a particular wireless 
network have a similar expiration time). 

The use of automatic deletion of short messages from 
subscriber queues 150 is important, e.g., in the case of churned MINs, so 
that a new subscriber does not receive lingering messages from a 
previous subscriber with the same MIN. 

Short messages to subscriber queues 150 may be delivered 
independently from one another and/or message delivery times spaced 
apart, thereby distributing message load over time and minimizing the 
negative effects of batch messaging on the wireless network. 

The MDC 100 can also or alternatively be configured to 
avoid sending batch messages during the carrier's busy hour(s), thereby 
minimizing load pressures on the wireless network. 

The use of an MDC 150 can aid the wireless carrier's 
network significantly, e.g., by forwarding short messages only when the 
relative handsets are turned on. Under this scenario, subscriber queues 
are not processed when the handset is powered off. This can reduce 
network storage requirements, delivery retry attempts, and overall SS7 
usage. The MDC 100 can do this either by interacting with appropriate 
applications, e.g., with a mobile chat location register (MCLR), or 
generally by intelligent use of SMS delivery receipt data from the SMSC 
and Web Gateway. A suitable mobile chat location register (MCLR) is 
shown and described in U.S. Appl. No. 09/814,363, entitled "Wireless 



Chat Automatic Status Tracking", filed March 23, 2001 by Ung et al. f the 
entirety of which is expressly incorporated herein by reference. 

The MDC 100 can further be configured to send content 
from various providers to certain SMPP ports on a short message service 
5 center (SMSC). The receipt of such content allows distinct billing records 
to be generated for each type of service, e.g., ads, general content, 
premium content, etc. 

Fig. 2 illustrates exemplary software components and their 
relationships in an embodiment of a message distribution center (MDC), in 

1 0 accordance with one embodiment of the present invention. 

In the disclosed embodiments, a Wireless Internet Gateway 
(WIG) was modified to include another 'dev/null' destination, which 
acknowledges short messages from a queueMonitor, but does not 
actually process them. The short messages remain in the Messages 

15 table of the database, where they are retrieved by a software component 
referred to herein as an "intelligent Delivery Agent" (IDA). The 
IDA retrieves messages from the Messages table in the database for 
subscribers, e.g., when they power on their handsets, subject to any 
desired rules. The IDA can become aware of subscriber power-ups 

20 through any appropriate trigger, e.g., via an SMPP Delivery Receipt 
mechanism, through Mobile Chat Location Register (MCLR) software, etc. 
Preferably, the IDA throttles short message traffic to any or all 
subscribers, e.g., optionally waiting until the busy hour is over before 
beginning the transmission. 

25 The MDC Gateway 100 may be, e.g., a standard WIG to 

which the provider sends messages through SMTP, RMI, HTTP, or 
suitable middleware software. As shown in Fig. 2, the MDC 100 includes 
a new DummyDestination, which simply acknowledges receipt from a 
particular subscriber queue 150, but does not attempt delivery. Delivery 

30 may be accomplished through an Intelligent Delivery Agent process, 
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which polls a messages table that is populated when the MDC Gateway 
100 receives relevant short messages. 

To most efficiently use the MDC gateway 100, the SMTP 
session preferably assigns the msgType property based on the sender's 
5 Email address and using InfoProviders information from the database. 
This allows the MDC Gateway 100 to determine that SMTP messages 
from an Information Provider (e.g., INFQ@NEWS.COM ) should use the 
Dummy Destination and be queried by the IDA. If the short message is 
submitted via an RMI mechanism, then the sender will explicitly define the 
10 msgType. 

When the MDC 100 inserts a short message record, an 
Oracle™ trigger may be used to create a subscriber record in the 
Subscribers table in the database if such a record does not already exist 
for the recipient. 

15 The Subscribers table may contain, preferably at a 

minimum, a MIN, status (e.g., 'Online 1 , 'Offline', 'Unknown'), and the time 
of the last status update. When first created, the status may default to 
'Unknown'. 

The IDA may be a separate program that delivers messages 
20 from the database to appropriate recipients via a RemoteSMPP RMI 
Interface of the carrier's gateway. The IDA preferably determines 
subscriber availability via, e.g., an MCLR or via Delivery Receipts. The 
former approach is likely more efficient, but the latter approach is more 
likely to work with most carrier environments. 
25 The Delivery Receipt method is considered to be more 

complicated. The Delivery Receipt method attempts to find the status of a 
subscriber's handset by examining delivery receipts from messages sent 
to the subscriber. 

As shown in Fig. 2, a SubscriberPoller agent 202 starts the 
30 process by gathering a list of subscribers from a Subscribers table 214 at 
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some time interval (z). If a particular subscriber is online, then the 
DeliveryAgent object 210 is notified. 

The DeliveryAgent 210 then gathers some pre-configured 
number of messages in time order for the subscriber from the Messages 
5 table 228 in the database, and sends them to the Carrier gateway 238 for 
delivery to the subscriber. There is no delivery receipt associated with 
these messages, so if the subscriber's handset is turned off the short 
messages are not delivered and not resent. This is why it is preferred that 
only a pre-configured number of short messages be sent before the 

10 subscriber's status is checked again by SubscriberPoller 202. 

If a subscriber's status is unknown, then a DRDeliverAgent 
234 is notified to send one message via the Carrier gateway 238 to the 
subscriber with a delivery receipt requested. When it sends the message, 
it sets the subscriber status as offline so that the SubscriberPoller 202 will 

1 5 ignore that subscriber. 

The delivery receipt will arrive at DR Listener 208. If the 
delivery receipt indicates failure, then the subscriber status is set as 
'unknown', otherwise the subscriber status is set as 'online'. The 
SubscriberPoller 202 wakes up shortly thereafter to take advantage of the 

20 user going online. 

Because there is no direct feedback from the handset, there 
is no conventional information received when a handset is turned off or 
on. DBSubStatusResetter 204 makes assumptions about how long a 
handset typically stays on or goes off. If a handset has been marked as 

25 online for a period of time (x), then DRSubStatusResetter 204 sets the 
corresponding subscriber status to 'unknown', which will restart the 
delivery receipt cycle again. If a subscriber has been marked as 'offline' 
for a different period of time (y), then the subscriber is marked as 
unknown, again restarting the delivery receipt cycle. 
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To summarize, there are three time periods involved in the 
Delivery Receipt method. Time x is the average time that a handset is 
online. Time y is the average time that a handset is offline. Time z is how 
often the Subscribers table 214 is polled for a list of subscribers. 
5 The three periods mentioned (x, y, and z) must have a 

certain relationship to one another. Time z must be smaller than time x 
and time y. Time x and time y's relationship to one another doesn't matter. 
Time z must be smaller than time x so that when a subscriber goes online, 
messages are sent to it before time x expires and online subscribers are 
10 set to 'unknown'. Time z should be smaller than time y, otherwise the 
^ subscriber will be sent another message before DR Listener 208 has had 

0 a chance to receive the delivery receipt. This implies that time z will also 

Q be longer than the expected time for a delivery receipt. 

^ A SubscriberCleanUp agent may be implemented to clean 

15 out subscribers that haven't had messages sent to them for a pre-defined 
period of time. This will ensure that the subscriber database doesn't grow 
5 without bound. Subscribers may have taken their name from the 

j** information provider's subscriber list. 

P Another technique mentioned above is to use an MCLR 

20 facility. In this situation, the MCLR will know explicitly when a handset is 
turned off or on. The MCLR Listener 218 then updates the Subscribers 
table 214 accordingly. The SubscriberPoller 202 always sees only online 
subscribers. It then uses the DeliveryAgent 210 to send the messages 
without a delivery receipt requested. 
25 When the MCLR Listener 218 is active, then the 

DRDeliverAgent 234, DR Listener 208, and DBSubStatusResetter 204 are 
all inactive. When the three delivery receipt entities are active, then the 
MCLR Listener 218 is inactive. 

The IDA Main 232 activates appropriate facilities based on a 
30 configuration file. 



In an MCLR implementation, the DRDeliveryAgent 234, DR 
Listener 208, and DRSubStatusResetter 204 may not be used. 

Fig. 3 is an exemplary class diagram which shows further 
details of an embodiment of a Message Distribution Center, in accordance 
5 with the principles of the present invention. In particular, Fig. 3 shows 
exemplary classes that may be activated and used to determine 
subscriber status and to actually deliver messages. 

As shown in Fig. 3, an IDA main class 318 is responsible for 
deciding which subscriber status determination strategy to use. The IDA 
10 class 318 may receive this information from a configuration file. The IDA 
class 318 instantiates and activates an MCLRListener class 314 if that 
facility is to be used to retrieve a handset's online/offline status. If the 
strategy is to use delivery receipts, then the IDA class 318 instead 
instantiates and activates the DRListener 322 and DRSubStatusResetter 
15 316 classes. 

A SubscriberPoller 306 class gets a list of subscribers 
whose status is 'unknown' or 'online' from the database. If a subscriber's 
status is 'unknown', the SubscriberPoller 306 invokes a method in a 
DeliveryAgent class 302 to send a message requesting a delivery receipt. 

20 If the subscriber's status is 'online', then the DeliveryAgent 302 sends 
messages without a delivery receipt to the subscriber. 

The DeliveryAgent 302 is responsible for averaging out the 
load on the carrier's system. It may do this by spreading out the 
messages over time, allowing normal traffic to be sent more quickly. The 

25 DeliveryAgent 302 may also hold off sending batch messages during the 
carrier's busy time. This information may be maintained in a configuration 
file and retrieved through a DeliverySetuplnfo class. 

The DeliveryAgent 302 can also be configured to send 
messages over certain SMPP ports to the carrier gateway 238 for tracking 

30 the amount of traffic that an information provider is sending. The 



DeliveryAgent 302 may accomplish this by tagging the message with a 
message type indicating that it is an MDC message. The configuration file 
may be set up so that messages of an MDC type will be sent to certain 
SMPP ports by the carrier gateway 238. 
5 Both the Subscribers 300 and Messages 304 classes may 

be wrappers around their respective database tables, to isolate JDBC 
calls to these classes only and/or to place the data in a useful format. 

The IDA 318 may send messages and/or decide blackout 
periods on a global basis, i.e., regardless of the destination of any 
10 particular message. One enhancement to this is to apply these on a per- 
n carrier basis since carriers can be in different time zones or have more or 

^ less capable hardware. 

y One advantage provided by the present invention is that 

q SMTP is a well-known protocol and an easy way for content providers to 

|!T 15 distribute their information. 

A Message Distribution Center (MDC) in accordance with 
p the principles of the present invention provides an ideal solution. It 

\2 addresses the problems faced by the carrier without requiring the 

] p information providers to change technologies. 

20 The principles of the present invention have applicability for 

usage with wireless intelligent network (WIN) and SMTP applications, e.g., 
those already otherwise containing a Internet gateway application for 
routing information through an SMTP gateway. Moreover, the MDC 
allows content providers to continue with their current mode of operation 
25 without placing the carrier's network at risk. The MDC can receive 
messages using a variety of protocols, including SMTP. It automatically 
routes messages to the appropriate carrier based on MIN range. Instead 
of delivering SMTP content directly to the carrier, it is delivered to the 
MDC. The MDC then ensures that the content is delivered in a 'carrier- 
30 friendly' manner. 
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MDC can provide the Info Provider with delivery statistics, 
e.g., what percentage of messages are being delivered. 

The MDC helps prevent the carrier from being overwhelmed 
by bulk messaging content and provides the following benefits: 

- bulk message traffic is distributed across time 

- messages are delivered over more efficient protocols than SMTP 
through the carrier's Wireless Internet Gateway 

- messages are only delivered when handsets are on, thereby 
eliminating network storage and retries 

- messages are delivered with appropriate urgency, delivery receipt, 
expiration times, and billing identifiers 

- individual bulk message queues allow the carrier to limit the number of 
messages that can be queued per subscriber 

- bulk messaging can be disabled for individual accounts when 
subscribers churn 

bulk message delivery statistics are available to the carrier via a 
web interface. 

While the invention has been described with reference to the 
exemplary embodiments thereof, those skilled in the art will be able to 
make various modifications to the described embodiments of the invention 
without departing from the true spirit and scope of the invention. 
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